Would

...exceeds the number of bytes remaining in the container.

be more accurate?

It took me a while to understand why you made this suggestion. It's because we're in an unchecked method, which means that we already believe we have enough data to finish the container. Therefore if peekIndex >= limit we're definitely past the container bounds because implicitly parent.endIndex < limit?

Another thing strikes me about this though- we check the same condition peekIndex >= limit on line 1551, and from my read the only thing that can change that condition in between there and here is this clause of uncheckedNextContainedToken():

        } else if (parent.typeId.type == IonType.STRUCT) {
            if (minorVersion == 0) {
                byte b = buffer[(int) peekIndex++];
                if (b < 0) {
                    fieldSid = (b & LOWER_SEVEN_BITS_BITMASK);
                } else {
                    fieldSid = (int) uncheckedReadVarUInt_1_0(b);
                }
            } else {
                uncheckedReadFieldName_1_1();
            }
        }

We must be in minorVersion == 0, and I note that uncheckedReadVarUInt_1_0(b) already contains a malformed data check. Does that mean that this error condition is discovered only when we've just read a 1-byte VarUInt field name, in the if (b < 0) { case above? In that case, should this error check go there, in uncheckedNextContainedToken()?

This code appears in the else branch which handles values below the top level:

if (parent == null) { // Depth 0
  // ...
} else {
  // the new code
}

I wasn't certain whether limit was the end of the stream's data or the end of the container's data in the buffer. Based on the location of the code, the latter seemed plausible.

Another thing strikes me about this though- we check the same condition peekIndex >= limit on line 1551, and from my read the only thing that can change that condition in between there and here is this clause of uncheckedNextContainedToken():

I wondered if reset() might affect peekIndex or limit, but didn't investigate further.

Would

...exceeds the number of bytes remaining in the container.

be more accurate?

Yes, this is more accurate.

We must be in minorVersion == 0, and I note that uncheckedReadVarUInt_1_0(b) already contains a malformed data check. Does that mean that this error condition is discovered only when we've just read a 1-byte VarUInt field name, in the if (b < 0) { case above? In that case, should this error check go there, in uncheckedNextContainedToken()?

I preferred to put this check in the proposed location, rather than in uncheckedNextContainedToken(), because the check protects the line that immediately follows (the access to the buffer at peekIndex). Note: uncheckedReadVarUInt_1_0 performs the check before each byte it consumes, but the added check protects access to the first byte after the field name.